Many fonts are stored in outline form and, when accessed by a printer, are "filled in" so as to evidence complete stroke representations of font characters. TrueType is an industry standard which defines the representation of certain computer outline font data. When the TrueType format is employed to represent large fonts (e.g. Kanji), memory requirements may exceed 2-5 megabytes. As such fonts are often stored in read only memory (ROM), large and expansive ROMs are required. A font may also be stored on a disk drive (e.g. in a computer operating system), or in random access memory (RAM) (e.g. fonts kept in a computer's main memory).
While reduction of font storage memory requirements is an ever-present objective, there is a parallel need to maintain compatibility with previously defined industry font standards (e.g. TrueType). In FIG. 1, a data processing system (e.g. a laser printer) is shown which is adapted to utilize TrueType outline font data. System 10 includes a microprocessor 12 that is connected via a bus system 14 to a laser print engine 16. Bus system 14 also connects to a ROM 18 that includes a TrueType font table 19 (to be discussed below with respect to FIG. 2). A random access memory (RAM) 20 is also connected to bus system 14, as is a print buffer 22. It is to be understood that print buffer 22 may be a portion of RAM 20.
An input/output module 24 is adapted to receive a message stream from a host computer that includes character codes. Each character code specifies a glyph which is the data that represents a character or a portion of a character and, when configured in pixel data form, can be stored in print buffer 22. In the case where a character comprises plural glyphs, one glyph will specify additional glyphs from which the complete character is built. Such pixel data, when provided to print engine 16, enables the deposition of ink on a media sheet that reproduces the glyph or glyphs.
When system 10 receives a message stream from a host computer that includes both character codes and print commands, the character codes are temporarily stored and are then converted to glyph data by reference to font table 19. The glyph data is stored in pixel form in print buffer 22 and is then provided to print engine 16.
FIG. 2 shows a TrueType font table 19, as it is stored in ROM 18 in FIG. 1. TrueType font table 19 comprises several subtables that are defined in the document TrueType Font Files Version 1.00, Microsoft Corporation, Redmond, Wash. TrueType font table 19 commences with a header 30 and a tag line 32 that forms an entry in directory portion 34. Tag line 32 includes a tag (i.e., a "name") identifying the table, a checksum for error correction purposes, a length field which defines the length of the table, and an offset value indicating the point at which the table begins after a directory portion 34.
Each TrueType font table 19 includes a number of tables, of which three subtables are a CMAP table 36, a LOCA table 38 and a GLYPH table 40. CMAP table 36 is addressed in accordance with a received character code and returns an associated glyph index value. Each glyph index value serves as an address into LOCA table 38 and is associated with an offset value. In response to a received glyph index value, LOCA table 38 returns an offset value which identifies the address offset within glyph table 40 wherein there is found pixel-data form of a glyph identified by the received character code. Glyph table 40, in a standard TrueType font table, occupies approximately 90 percent of ROM 18 and, as above indicated, may be as large as 2-5 megabytes.
Once a glyph has been accessed from glyph table 40, it is processed, using a "fill" procedure 42 stored in RAM 20 in FIG. 1. Fill procedure 42 enables the outline glyph data to be completely "filled in" so that the pixel data in print buffer 22 represents a fully filled-in character. At this stage, a glyph in print buffer 22 is ready for printing by print engine 16. If the glyph data from glyph table 40 includes only a portion of a character, a further procedure is employed to associate the glyphs to arrive at a complete character.
It is therefore an object of this invention to provide a data processing system which minimizes font storage requirements by storing the font data in a compressed form.
It is another object of this invention to provide a data processing system with compressed format font storage that is compatible with pre-existing font standards.
It is yet another object of this invention to provide a data processing system with compressed font storage and to further provide decompression procedures that enable a most efficient decompression action to be carried out with respect to individual stored glyphs.